home *** CD-ROM | disk | FTP | other *** search
Text File | 1995-04-11 | 43.6 KB | 1,094 lines |
- Posted-By: auto-faq 3.1.1.2
- Archive-name: graphics/fileformats-faq/part1
- Posting-Frequency: monthly
- Last-modified: 01Mar95
-
- This FAQ (Frequently Asked Questions) list contains information on graphics
- file formats, including, raster, vector, metafile, Page Description Language,
- 3D object, animation, and multimedia formats.
-
- This FAQ is divided into four parts, each covering a different area of
- graphics file format information:
-
- Graphics File Formats FAQ: General Graphics Format Questions (Part 1 of 4)
- Graphics File Formats FAQ: Image Conversion and Display Programs (Part 2 of 4)
- Graphics File Formats FAQ: Where to Get File Format Specifications (Part 3 of 4)
- Graphics File Formats FAQ: Tips and Tricks of the Trade (Part 4 of 4)
-
- Please email contributions, corrections, and suggestions about this FAQ to
- jdm@netcom.com. Relevant information posted to newsgroups will not
- automatically make it into this FAQ.
-
- -- James D. Murray <jdm@netcom.com> ;-{)>>>>
-
- ----------------------------------------------------------------------
-
- Subject: 0. Contents of General Graphics Format Questions
-
- Subjects marked with <NEW> are new to this FAQ.
- Subjects marked with <UPD> have been updated since the last release
- of this FAQ.
-
- I. General questions about this FAQ
-
- 0. Maintainer's Comments
- 1. What's new in this latest FAQ release?
- 2. Why does a graphics formats FAQ exist?
- 3. Where can I get the latest copy of this FAQ? <UPD>
- 4. Are there other related FAQs I should read as well? <UPD>
- 5. I have a question, correction, or some information concerning this FAQ.
- 6. This FAQ doesn't contain enough detail!
- 7. Why isn't the XXX file format covered?
- 8. Why aren't audio file formats covered?
- 9. Why aren't word processing formats covered?
- 10. What about multimedia file formats?
-
- II. General Graphics File Questions
-
- 0. Who cares about graphics file formats?
- 1. What is raster, vector, metafile, PDL, and so forth?
- 2. Why should I care about previous versions of a file format?
- 3. Can graphics files be infected with a virus? <UPD>
- 4. Can graphics files be encrypted?
- 5. Can a graphics file be copyrighted?
- 6. How can I convert the XXX format to the YYY format?
- 7. Do I really need the specification of the format I'm using?
- 8. How can I tell if a graphics file is corrupt? <NEW>
-
- V. Graphics Formats Misnomers, Misgivings, and Miscellany
-
- 0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4 file formats?
- 1. Why aren't IGES, GKS, NAPLPS, and HPGL file formats either? <NEW>
- 2. Is it "Tag" or "Tagged" Image File Format?
- 3. Whaddya mean there's no "Targa" file format?
- 4. Choosy programmers choose "gif" or "jif"?
- 5. Why are there so many ".PIC" and ".IMG" formats?
- 6. Is it now illegal to use CompuServe's GIF format?
-
- III. Graphics File Resources
-
- 0. File Format Specifications FTP Archives <UPD>
- 1. Graphics and Image File FTP Archives and WWW pages <UPD>
- 2. Internet Mailing Lists for Graphics and Imaging
- 3. Books on Graphics File Formats <UPD>
- 4. Magazine Articles on Graphics File Formats <UPD>
- 5. U.S. Government and Military Standards Sources <UPD>
- 6. Other Standards Document Sources <NEW>
-
- VII. Kudos and Assertions
-
- 0. Acknowledgments
- 1. About The Author
- 2. Disclaimer
- 3. Copyright Notice
-
- ------------------------------
-
- Subject: I. General questions about this FAQ
-
- ------------------------------
-
- Subject: 0. Maintainer's Comments
-
- Welcome to another monthly release of the Graphics File Format FAQ!
-
- If you've been following the progress of this FAQ you'll now note that it has
- been split into four physical parts to accommodate its growing size. These
- parts are logically divided as follows:
-
- Graphics File Formats FAQ: General Questions (Part 01 of 4)
- Graphics File Formats FAQ: Image Conversion and Display Programs (Part 02 of 4)
- Graphics File Formats FAQ: Where to Get File Format Specifications (Part 03 of 4)
- Graphics File Formats FAQ: Tips and Tricks of the Trade (Part 4 of 4)
-
- ------------------------------
-
- Subject: 1. What's new in this latest FAQ release?
-
- o Included a blurb on corrupt graphics files
- o More "that isn't a file format!" information
- o Updated file format archive sites
- o Added new FAQs you should read
- o Yet another magazine article(s) added
- o And more sources for military documents
-
- ------------------------------
-
- Subject: 2. Why does a graphics formats FAQ exist?
-
- The purpose of this FAQ is to answer many of the frequently asked questions
- about graphics file formats posted on Usenet. You will find definitions of
- terms, references to format information, very general descriptions of many
- formats, information on programs which read, write, convert, and display
- graphics files, and some handy programming tips for writing your own code.
- This FAQ is not a substitute for actual file format specifications, nor can
- it possibly go into a great amount of specific detail on graphics file
- formats.
-
- ------------------------------
-
- Subject: 3. Where can I get the latest copy of this FAQ?
-
- This FAQ is distributed monthly on the Usenet newsgroups comp.graphics
- comp.answers, and news.answers as four separate files. It may also be
- obtained via anonymous FTP from:
-
- ftp://rtfm.mit.edu/pub/usenet/news.answers/graphics/fileformats-faq
- ftp://rtfm.mit.edu/pub/usenet/comp.graphics
-
- To receive a copy of this FAQ via email, send an email message to
- mail-server@rtfm.mit.edu with the body:
-
- send usenet/news.answers/graphics/fileformats-faq/part1
- send usenet/news.answers/graphics/fileformats-faq/part2
- send usenet/news.answers/graphics/fileformats-faq/part3
- send usenet/news.answers/graphics/fileformats-faq/part4
-
- or via UUCP:
-
- uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part1
- uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part2
- uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part3
- uunet!/archive/usenet/news.answers/graphics/fileformats-faq/part4
-
- To access this FAQ on the World Wide Web, use the address:
-
- http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/fileformats-faq/faq.html
-
- And you can access all of the FAQs associated with comp.graphics via the
- WWW page:
-
- http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/top.html
-
- ------------------------------
-
- Subject: 4. Are there other related FAQs I should read as well?
-
- Information related to file formats not covered by this FAQ may be
- found in the following FAQs:
-
- Newsgroup Archive-name
-
- alt.binaries.pictures pictures-faq/part[1-2]
- alt.graphics.pixutils pixutils-faq
- alt.image.medical medical-image-faq/part[1-3]
- comp.compression compression-faq/part[1-3]
- mpeg-faq[1-6]
- comp.dsp dsp-faq[1-4]
- audio-fmts[1-2]
- comp.fonts fonts-faq/part[1-2]
- comp.graphics graphics/faq
- graphics/colorspace-faq
- graphics/resources-list/part[1-3]
- jpeg-faq/part[1-2]
- comp.graphics.animation graphics/animation-faq
- comp.infosystems.gis geography/infosystems-faq
- comp.multimedia comp-multimedia-faq
- comp.speech comp-speech-faq/*
- comp.sys.sgi.misc sgi/faq/*
- sci.data.formats sci-data-formats
- sci.image.processing image-processing/Macintosh
-
- These FAQs may also be found the newsgroups alt.answers, comp.answers,
- sci.answers, and news.answers, and in the FAQ archives at rtfm.mit.edu
- and mirror sites.
-
- To FTP any of these FAQs use the listed Archive-name with the following FTP
- address:
-
- ftp://rtfm.mit.edu/pub/usenet/news.answers/[Archive-name]
-
- To receive a copy of these FAQs via email, send an email message to
- mail-server@rtfm.mit.edu with the body:
-
- send usenet/news.answers/[Archive-name]
-
- ------------------------------
-
- Subject: 5. I have a question, correction, or some information concerning this FAQ.
-
- All questions, comments, additions, and corrections should be sent to the
- author of this FAQ at jdm@netcom.com. I don't always read the newsgroups this
- FAQ is posted to, so please contact me directly via email rather than
- attempting to reach me by posting to a newsgroup. All suggestions and
- contributions within the scope of this FAQ are welcome and contributors
- receive full credit in the Acknowledgments section of this FAQ.
-
- ------------------------------
-
- Subject: 6. This FAQ doesn't contain enough detail!
-
- This FAQ only attempts to answer Frequently Asked Questions. It is not a book
- on graphics file formats. It is instead a thick source of information that
- will help you obtain more information that you need. Or perhaps even clear
- up a few of your misconceptions and thereby saving you from wasting some
- time.
-
- ------------------------------
-
- Subject: 7. Why isn't the XXX file format covered?
-
- If you have read and/or grepped this FAQ and not found information on the
- format you need the reason might be that:
-
- * You are looking for the format under the wrong name.
-
- * This FAQ is new and the information you need hasn't been included yet.
-
- * I don't know about the format and I need you to email me information
- on it (See 4.).
-
- * The format is proprietary and its caretakers do not wish information
- on the format distributed in this FAQ.
-
- ------------------------------
-
- Subject: 8. Why aren't audio file formats covered?
-
- Information on file formats used specifically for storing audio data are
- already covered quite nicely by a FAQ posted to comp.dsp. You may obtain
- this FAQ from the Usenet newsgroups comp.dsp, comp.answers, and news.answers,
- or from the FTP archive site (and mirrors):
-
- ftp://rtfm.mit.edu/pub/usenet-by-group/comp.dsp
-
- The FAQ for comp.speech may of also be of interest to audio people. It is
- available at:
-
- ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/FAQ-complete
- ftp://rtfm.mit.edu/pub/usenet/news.answers/comp-speech-faq/*
-
- ------------------------------
-
- Subject: 9. Why aren't word processing formats covered?
-
- It is true that there are many types of file formats that cannot store
- graphics data (older word processor and spreadsheet formats, and so forth).
- These formats are not within the scope of this FAQ and are therefore not
- covered. Perhaps someone who works in the biz of writing file translators for
- these formats will put together such a FAQ one day.
-
- ------------------------------
-
- Subject: 10. What about multimedia file formats?
-
- Multimedia file formats store more than just graphics data. They may also
- contain audio, video, animation, and textual data in addition to bitmapped
- and vectored graphics. Such formats, although a superset of graphics formats,
- are considered to be within the scope of this FAQ and are therefore covered.
- Also check the comp.multimedia FAQ for additional information you may
- require.
-
- ------------------------------
-
- Subject: II. General Graphics File Questions
-
- ------------------------------
-
- Subject: 0. Who cares about graphics file formats?
-
- Well, programmers do mostly. But end-users (that is, non-programmers) do too.
-
- The typical end-user only cares about storing their graphics information
- using a format that most graphics programs and filters can read. End-users
- are typically not concerned with the internal arrangement of the data within
- the graphics file itself. They only want the format to do its job by
- representing their data correctly in a permanent form.
-
- Programmers, on the other hand, are that rare breed of human that just can't
- leave information well enough alone. They need to know how every byte is
- arranged to see if someone knows something that they don't (and often snicker
- contentedly to themselves when they find that it is really they that know
- more). Programmers will then use this information to write code that may
- never see the light of distribution, but nevertheless, they will have had fun
- and gained enlightenment from writing it.
-
- It doesn't matter which of these two types of people you are. If you have
- even the slightest interest in graphics file formats then you may be counted
- as one who cares.
-
- ------------------------------
-
- Subject: 1. What is raster, vector, metafile, PDL, and so forth?
-
- These terms are used to classify the type of data a graphics file contains.
- Raster files (also called bitmapped files) contain graphics information
- described as pixels, such as photographic images. Vector files contain data
- described as mathematical equations and are typically used to store line art
- and CAD information. Metafiles are formats that may contain either raster or
- vector graphics data. Page Description Languages (PDL) are used to describe
- the layout of a printed page of graphics and text. Animation formats are
- usually collections of raster data that is displayed in a sequence.
- Multi-dimensional object formats store graphics data as a collection of
- objects (data and the code that manipulates it) that may be rendered
- (displayed) in a variety of perspectives. Multimedia file formats are
- capable of storing any of the previously mentioned types of data, including
- sound and video information.
-
- ------------------------------
-
- Subject: 2. Why should I care about previous versions of a file format?
-
- When version 2.0 of the XXX format is released all of the thousands of files
- created using version 1.0 of the XXX format don't magically disappear or
- transform to version 2.0 overnight. Although version 2.0 might claim to be
- fully backwards compatible, the new specification may obfuscate or even omit
- details of the previous version of the format. In short, never throw away
- older information just because you have something newer. At one point in time
- that "out dated" format spec was state-of-the-art, and it may still contain a
- singular precious tid-bit of information that the caretakers of the format
- didn't carry over to the new spec (but Murphy will make sure you desperately
- need to know).
-
- ------------------------------
-
- Subject: 3. Can graphics files be infected with a virus?
-
- For most types of graphics file formats currently available the answer is
- "no". A virus (or worm, Trojan horse, and so forth) is fundamentally a
- collection of code (that is, a program) that contains instructions which are
- executed by a CPU. Most graphics files, however, contain only static data
- and no executable code. The code that reads, writes, and displays graphics
- data is found in translation and display programs and not in the graphics
- files themselves. If reading or writing a graphics file caused a system
- malfunction is it most likely the fault of the program reading the file and
- not of the graphics file data itself.
-
- With the introduction of multimedia we have seen new formats appear, and
- modifications to older formats made, that allow executable instructions to be
- stored within a file format. These instructions are used to direct multimedia
- applications to play sounds or music, prompt the user for information, or
- display other graphics and video information. And such multimedia display
- programs may perform these functions by interfacing with their environment
- via an API, or by direct interaction with the operating system. One might
- also imagine a truly object-oriented graphics file as containing the code
- required to read, write, and display itself.
-
- Once again, any catastrophes that result from using these multimedia
- application is most like the result of unfound bugs in the software and not
- some sinister instructions in the graphics file data. Such "logic bombs" are
- typically exorcised through the use of testing using a wide variety of
- different image files for test cases.
-
- If you have a virus scanning program that indicates a specific graphics file
- is infected by virus, then it is very possible that the file coincidentally
- contains a byte pattern that the scanning programming recognizes as a key
- byte signature identifying a virus. Contact the author (or even read the
- documentation!) of the virus scanning program to discuss the probability of
- the mis-identification of a clean file as being infected by a virus. Save the
- graphics file, as the author will most likely wish to examine it as well.
-
- If you suspect a graphics file to be at the heart of a virus problem you are
- experiencing, then also consider the possibility that the graphics file's
- transport mechanism (floppy disk, tape or shell archive file, compressed
- archive file, and so forth) might be the original source of the virus and not
- the graphics file itself.
-
- ------------------------------
-
- Subject: 4. Can graphics files be encrypted?
-
- Of course you can encrypt a graphics file. After all, most encryption
- algorithms don't care about the intellectual content of a file. All they chew
- on is a series of byte values. Therefore, most any encryption program that
- works on ordinary text files will work on graphics files as well.
-
- Why would you want to encrypt a graphics file? Mostly to control who can view
- its contents. You can invent a proprietary file format and that might slow a
- file format hack down for, say, five or ten minutes. You could add a
- proprietary data compression scheme, possibly a twisted variation of an
- already public algorithm. But there are so many people out there with nothing
- better to do than hack at unknown data formats that your data would probably
- be exposed in little time. But suppose we top off all this effort by
- encrypting the graphics file itself as we would an ordinary text file. Would
- your data then be safe?
-
- Realize that an encrypted graphics file still might not be very secure. For
- every data encryption algorithm there exists at least one method of getting
- around it, although it may take hundreds of computers and many years to fully
- employ and execute that method!
-
- For example, one of the more popular methods used to encrypt data is the
- Vernam or XOR cipher. This cipher Exclusive ORs the plain-text data with a
- single, random, fixed-length key. The longer the key the harder it is to
- break the cipher. A totally random key the length of your data is impossible
- to break. Shorter and less-random keys are easier to break.
-
- XOR is very simple and fast, which is a must for a graphics file
- translator/viewer that must decrypt a file on the fly. A problem, however, is
- that most graphics files contain fixed size headers which vary only slightly
- in content from file to file. If you knew the approximate contents of the
- header of an encrypted file you could XOR a "decrypted" header with the
- encrypted file and possibly produce the key used to encrypt the file. A short
- key might be very easily discovered in this way.
-
- If you really need to make the contents of a graphics file secure, then I'd
- suggest not only using some form of data encryption, but also create an
- unconventional and proprietary file format and do not publish its format
- specification.
-
- For more info on data encryption:
-
- Bruce Schneier, "Applied Cryptography: Protocols, Algorithms,
- and Source Code in C", John Wiley & Sons, 1994.
-
- ------------------------------
-
- Subject: 5. Can a graphics file be copyrighted?
-
- No. A graphics file cannot normally be copyrighted under United States
- copyright laws (although the rulings of some judges may disagree on this). The
- specification of a format and the contents of a graphics file, however, are
- subject to copyright.
-
- For anything to be copyrighted it must be:
-
- 1) A work of authorship
- 2) Fixed in a tangible medium of expression
-
- The description of a graphics format does meet both of these criteria (it is
- fixed in a medium and a work of authorship) and is therefore protected under
- the copyright laws. A graphics file created using the format description,
- however, meets the second criteria, but not the first (that is, it is not
- considered to be a work of authorship). The format itself is considered
- instead to be an idea or system, and is therefore not protected by copyright.
-
- So the description of a file format is copyrightable, but the format as it
- exists in its medium is not. What about the graphics data that the file
- contains?
-
- If the graphical data written to a graphics file also meets the above two
- criteria, then it is also protected by the copyright laws as intellectual
- property. You will not wave your copyright protection by storing any original
- information using a graphics file format.
-
- ------------------------------
-
- Subject: 6. How can I convert the XXX format to the YYY format?
-
- With a file conversion program, of course! Without a doubt one of the most
- frequently asked categories of questions on comp.graphics is how to convert
- one format to another. In every case the answer is some type of conversion
- program or filter, but which one?
-
- Section IV of the FAQ is an attempt to list every known graphics file display
- and conversion program and application. Although far from complete, this list
- may contain the program you need. Go to the subsection of the particular
- operating system you are using and scan through Imports: and Exports: formats
- listed and see if the formats you needs to use are there.
-
- In some cases the information in a listing may make the conversion
- capabilities of a program a bit misleading. For example, a program that can
- import a vector .DWG file and export a raster .BMP file may not necessarily
- be able to perform a .DWG->.BMP (vector->raster) conversion (AutoCAD R12 can,
- BTW). And just because a program can both import and export TIFF files
- doesn't mean it's capable of a TIFF(CMYK)->TIFF(RGB) conversion (as Adobe
- Photoshop can do). As always, read the documentation, contact and ask the
- author of the program, or find a user of the program and ask them.
-
- ------------------------------
-
- Subject: 7. Do I really need the specification of the format I'm using?
-
- It depends upon the results you are trying to obtain. If you have code that
- supports the XXX format and you find it easy (and legal) to integrate that
- code into your program, then you may be tempted to do so. But realize that
- your program will support the XXX format in just the same way as the previous
- program did. In other words, your program will now work the same, but it will
- really be no better.
-
- By obtaining the format specification you can make an attempt to fully
- support all of the features and capabilities a graphics or multimedia file
- format has to offer. If you use pre-written code that only supports a small
- subset of the format's features then you are not doing justice to the
- format and cheating your users out of functionality they might need.
-
- Always strive to create the best programs possible within reason of time and
- money. Obtain the specs, look at code, and talk to programmers who have
- worked with the format before. You might gain some insight and save yourself
- some hair-pulling by supporting a feature that someone didn't think to
- include in the original requirements for your program.
-
- ------------------------------
-
- Subject: 8. How can I tell if a graphics file is corrupt?
-
- The easiest way is to display the file and decide if what you see on the
- screen or the printer is correct. This method is not fool-proof, however,
- because not all information stored in a graphics file is used for displaying
- the data it contains. Textual comments, alternate color maps, and unused
- fields in the header might be munged and go undetected.
-
- The standard way to check for corruption of any type of data file is to
- perform some sort of error-detection scheme on the file. Such schemes used
- are Checksum, Cyclic Redundancy Check (CRC), Longitudinal Redundancy Check
- (LRC), and Vertical Redundancy Check (VRC). These algorithms are common in
- the world of synchronous serial communications for detecting errors in data
- streams.
-
- Most graphics files do not contain the built-in feature of error detection.
- If you only wanted to provide error detection for the graphical data
- contained in a file, but not the header, then a 2- or 4-byte field in the
- header could be used to store the CRC-16 or CRC-32 value of the data. But
- what good is pure data if the header is possibly corrupt? If we calculate the
- CRC value of the entire file and then store that calculated value in the
- header we will have just "corrupted" the file! You could initialize the field
- with zeros, calculate the value, store the value, and specify that the entire
- file need be read into memory and the CRC value field set to all zeros before
- the CRC calculation is made. Quite a pain, really. Can't we just store the
- CRC value externally to the file? Maybe use some sort of encapsulating
- "wrapper"?
-
- If you want to make sure a graphics file (or any file for that matter) has
- been transported through a communications channel without sustaining any
- corruption, first store it using a file archiving program that supports error
- checking of the files contained in the archive. (Several good error-checking
- file archiving programs include PKZIP, gzip, and zoo. ar and tar do not
- support error checking). When the graphics file is stored the archival
- program calculates the CRC value of the file. If the CRC value does not match
- when the file is unarchived after transport, you know that the file has been
- corrupted.
-
- One extra tip: make sure you turn compression OFF when archiving many
- graphics files. File archival programs use compression by default and will
- attempt to make your compressed data even smaller (which usually results in
- larger data, unless the archiver is smart enough to detect the negative
- compression and not attempt to compress the file). ASCII-based files (such as
- PostScript and DXF) and some RLE-encoded files (such as PCX) will be
- compressed, while other formats supporting more advanced data encoding
- methods (such as JPG and GIF) will surely grow in size.
-
- ------------------------------
-
- Subject: III. Graphics File Resources
-
- ------------------------------
-
- Subject: 0. File Format Specifications FTP Archives
-
- The following anonymous FTP and WWW sites are known to archive file format
- specifications and information. These documents may be official releases of
- specifications by the creator/caretaker of the formats, or information
- transcribed by people from various sources and released onto the net,
- possibly without permission from the format's owner.
-
- ftp://avalon.chinalake.navy.mil/pub/format_specs
- ftp://avalon.vislab.navy.mil/pub/format_specs
- ftp://ftp.nau.edu/graphics/formats
- ftp://ftp.ncsa.uiuc.edu:/misc/file.formats/graphics.formats
- ftp://ftp.std.com/obi/Standards/Graphics/Formats
- ftp://ftp.uu.net/doc/literary/obi/Standards/Graphics/Formats
- ftp://ftp.wustl.edu/doc/graphic-formats
- ftp://peipa.essex.ac.uk/ipa/file.formats
- ftp://telva.ccu.uniovi.es/pub/graphics/file.formats
- ftp://x2ftp.oulu.fi/pub/msdos/programming/formats
- ftp://zamenhof.cs.rice.edu/pub/graphics.formats
-
- http://www.dcs.ed.ac.uk/home/iat/index.html
-
- ------------------------------
-
- Subject: 1. Graphics and Image File FTP Archives and WWW pages
-
- The following anonymous FTP sites are known to archive image, graphics, and
- multimedia files and information:
-
- ftp://ames.arc.nasa.gov/pub/SPACE
- NASA/Ames Archives. Space images in GIF format.
-
- ftp://amiga.physik.unizh.ch/amiga/gfx/misc
- VistaPro graphics
-
- ftp://asterix.inescn.pt/pub/PC/flidemos
- FLI and FLC animations
-
- ftp://ftp.catt.ncsu.edu/pub/graphics
- FLIC and QuickTime movies and many GIF and JPG images
-
- ftp://ftp.cdrom.com/pub/aminet/pix
- JPG, GIF, and Multimedia files
-
- ftp://ftp.cnam.fr/Fractals/anim
- Fractal animation files
-
- ftp://edcftp.cr.usgs.gov/pub/data/DEM/250
- ftp://edcftp.cr.usgs.gov/pub/data/DLG/{2M,100K}
- Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
-
- ftp://ftp.povray.org/pub/povray/images
- ftp://ftp.povray.org/pub/povray/scenes
- GIF, JPEG, and POV scene files rendered using PovRAY
-
- ftp://ftp.sdsc.edu/pub/sdsc/images
- ftp://ftp.sdsc.edupub/sdsc/sound
- San Diego Supercomputer Center sound and image file archives
-
- ftp://ftp.sunet.se/pub/graphics
- ftp://ftp.sunet.se/pub/multimedia
- MPEG, JPEG, FLC, HDF, AF, VR, and GIF files.
- Also /pub/pictures and /pub/comics contain many images
-
- ftp:://ftp.tcp.com/pub/anime
- ftp:://ftp.tcp.com/pub/anime-manga/anim
- Animation and multimedia files in MPEG, QuickTime, AVI, and FLI formats
-
- ftp:://omicron.cs.unc.edu/pub/softlab/CHVRTD
- MRI and CT scan volume data of human anatomy
-
- ftp://photo1.si.edu/images
- Smithsonian Institution photoimage archives
-
- ftp://ftp.povray.org
- POV animation files
-
- ftp://pubinfo.jpl.nasa.gov/images
- Space images in GIF format
-
- ftp://spectrum.xerox.com/pub/map/dem
- ftp://spectrum.xerox.compub/map/dlg
- Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
-
- ftp://src.doc.ic.ac.uk/gfx/misc
- Digital Elevation Model (DEM) and Digital Line Graph (DLG) archives
-
- ftp://sunsite.unc.edu/pub/multimedia/pictures
- ftp://sunsite.unc.edu/pub/multimedia/animation
- Graphics and MPEG file collection
-
- ftp://toybox.gsfc.nasa.gov/pub/images
- NASA images in GIF, JPEG, PostScript, Sun Raster, and X Bitmap formats
-
- Red's Nightmare (a ray-traced animation)
- ftp://ftp.uni-erlangen.de/pub/pictures/mpeg/LOCAL/RedsNightmare.tar
-
- ftp://ftp.univ-rennes1.fr/Images/ASTRO/anim
- Space animation files
-
- ftp://ftp.wustl.edu/pub/aminet/gfx/anim
- Various Amiga anims (also on other aminet sites)
-
- The following WWW sites are known to archive image, graphics, and multimedia
- files:
-
- http://afrodite.lira.dist.unige.it/
- European Network of Excellence in Computer Vision
-
- Mat Carr's animations
- http://archpropplan.auckland.ac.nz/People/Mat/gallery/animations.html
-
- http://cui_www.unige.ch:80/OSG/MultimediaInfo/
- Index to Multimedia Information Resources
-
- http://found.cs.nyu.edu/
- NYU State Center for Advanced Technology
-
- http://fuzine.mt.cs.cmu.edu/im/informedia.html
- Informedia Digital Video Library Project
-
- http://mambo.ucsc.edu:80/psl/thant/thant.html
- Thant's Animation index
-
- http://netlab.itd.nrl.navy.mil/imaging.html
- Listings of imaging resources and archive sites
-
- http://scorch.doc.ic.ac.uk/~np2/multimedia/
-
- http://sunsite.unc.edu/louvre/about/tech.html
- http://mistral.enst.fr/louvre/about/tech.html
- WebLouvre - Using and troubleshooting the web
-
- http://w3.eeb.ele.tue.nl/mpeg/index.html
- Various MPEG animations
-
- http://web.msi.umn.edu/WWW/SciVis/umnscivis.html
- Scientific visualization and graphics
-
- http://www.best.com/~bryanw/index.html
- The Graphics Archive
-
- http://www.cs.ubc.ca/nest/imager/imager.html
- MPEG animations done using hierarchical b-splines
-
- http://www.delphi.com/fx/fxscreen.html
- fX Networks' Download Goodies promo videoclips in AVI and QT formats
-
- http://www.demon.co.uk/
- Demon Internet
-
- http://www.infomedia.com:8600
- Liquid Mercury's new WWW Site designed for "New Media" professionals.
- Current industry data and product profiles. Email: info@infomedia.com
-
- http://www.lightside.com/~dani/cgi/images-index.html
- 3DWEB - World Wide Web site for 3D Computer Graphics
-
- http://www.sd.tgs.com/~template
- Web3D - World Wide Web site for 3D Graphics
-
- http://www.state51.co.uk/state51/
- State51 Interactive Media
-
- http://www.yak.net/pub/emptystreet/emptystreet.html
-
- http://www.univ.trieste.it/mmwwwpc/mmwwwpc.html
- MultiMedia WWW PC v1.1
-
- ------------------------------
-
- Subject: 2. Internet Mailing Lists for Graphics and Imaging
-
- This section contains a listing of Internet mailing lists that often contain
- discussions and information on graphics and image file formats. Mailing lists
- are a good alternative form of communication for those netters that do not
- have Usenet access.
-
- agocg-ip@mailbase.ac.uk
- Discussion of all aspects of image processing. To subscribe:
- send an email message to mailbase@mailbase.ac.uk with the body
- "join agocg-ip yourfirstname yourlastname".
-
- digvid-l@ucdavis.edu
- Discussion of digital video, mostly of the desktop variety.
- To subscribe: send an email message to listserv@ucdavis.edu
- with the body: "subscribe digvid-l yourfirstname yourlastname".
-
- geotiff@tazboy.jpl.nasa.gov.
- Discussion regarding the establishment of a set of TIFF tags for
- storing geographic map projection information, such as UTM zones,
- Lambert Standard parallels, etc. Participants include
- representatives from SPOT, Intergraph, ERDAS, ESRI, and USGS. To
- subscribe: send an email message to geotiff-request@tazboy.jpl.nasa.gov.
-
- listserv@info.kodak.com
- Information on the Kodak Photo-CD format. To subscribe: send an
- email message to listserv@info.kodak.com with the body:
- "INFO PHOTO-CD".
-
- listserv@soils.umn.edu
- NIH image processing discussion. To subscribe: send an email message
- to listserv@soils.umn.edu with the body "subscribe nih-image
- yourfirstname yourlastname".
-
- medimage@polygraf
- Medical imaging discussion. To subscribe: send an email message
- to listserv%polygraf.bitnet@mitvma.mit.edu with the body
- "subscribe medimage".
-
- nucmed@uwovax.uwo.ca
- Nuclear medicine and medical imaging discussion. To subscribe:
- send an email message to nucmed-request@uwovax.uwo.ca with the
- body "subscribe nucmed".
-
- pixel@essex.ac.uk
- British Machine Vision Association newsletter for machine vision,
- image processing, pattern recognition, remote sensing, etc. To
- subscribe: send an email message to pixel-request@essex.ac.uk.
-
- ximage@expo.lcs.mit.edu
- Discussion of image processing using The X Window System. To
- subscribe send an email message to ximage-request@expo.lcs.mit.edu
- with the body "subscribe ximage".
-
- ------------------------------
-
- Subject: 3. Books on Graphics File Formats
-
- This section contains bibliographical listing of books containing information
- on graphics file formats. This list is alphabetized by title and information
- on how to order each book is included where known.
-
- The AutoCAD Database Book, F.H. Jones and L. Martin, Ventana Press,
- ISBN 0-940087-04-9. Order: 919.490.0062 voice.
-
- Bit-mapped graphics (2nd ed.), Steve Rimmer, Windcrest/McGraw-Hill
- 1993. 484 pages.
-
- CGM and CGI: Metafile and Interface Standards for Computer
- Graphics, David B. Arnold and Peter R. Bono, Springer-Verlag
- 1988. ISBN 3-540-18950-5, 279 pages.
-
- The CGM Handbook, Lofton R. Henderson and Anne M. Mumford,
- Academic Press 1993. ISBN 0-12-510560-6, $59.95 hardcover,
- 446 pages.
-
- Encyclopedia of Graphics File Formats, James D. Murray and
- William vanRyper, O'Reilly & Associates Inc. 1994.
- ISBN 1-56592-058-9, $59.95 softcover, 928 pages.
- Order: order@ora.com, 800.998.9938 voice, 707.829.014 fax.
-
- File Formats for Popular PC Software: A Programmer's Reference,
- Walden, Jeff, John Wiley & Sons, Inc. 1986. ISBN 0-471-83671-0,
- 287 pages.
-
- Graphics File Formats (2nd ed.), David C. Kay and John R. Levine,
- Windcrest Books/McGraw-Hill 1995. ISBN 0-07-034025-0, $26.95
- softcover, 476 pages.
- Order: Tab Software Department, Blue Ridge Summit, PA 17294-0850.
-
- The Graphic File Toolkit: Converting and Using Graphic Files,
- Steve Rimmer, Addison-Wesley, 1992. 335 pages.
-
- Inside Windows File Formats, Tom Swan, Sams Publishing 1993.
- ISBN 0-672-30338-8 $24.95 softcover, 337 pages.
- Order: Sams Publishing, 2201 West 103rd Street, Indianapolis,
- IN 46290
-
- More File Formats for Popular PC Software: A Programmer's Reference,
- Jeff Walden, John Wiley and Sons 1987. 369 pages.
-
- PC Graphics with GKS, P.R. Bono, J.L. Encarnacao and W.R. Herzner,
- Prentice-Hall, 1990.
-
- PostScript Language Reference Manual, Adobe Systems Inc. (2nd ed.),
- Ed Taft and Jeff Walden, Addison-Wesley 1990.
-
- Programming for Graphics Files in C and C++, by John R. Levine,
- John Wiley & Sons 1994. ISBN 0-471-59854-2, $29.95 softcover,
- 494 pages.
-
- ------------------------------
-
- Subject: 4. Magazine Articles on Graphics File Formats
-
- This section contains bibliographical listings of periodicals containing
- information on graphics file formats. This list is alphabetized by title.
-
- .mrb and .shg File Formats, Windows/DOS Developer's Journal, Pete Davis,
- February 1994 (Vol 5, No 4), pp. 37-46.
-
- The BMP File Format, Dr. Dobb's Journal, Marv Luse, #219 September
- 1994 (Vol 9, Issue 10), pp. 18-22.
-
- The BMP File Format: Part I, Dr. Dobb's Journal, David Charlap, #228
- March 1995 (Vol. 20, Issue 3).
-
- The BMP File Format: Part II, Dr. Dobb's Journal, David Charlap, #229
- April 1995 (Vol. 20, Issue 4).
-
- PCX Graphics, C Users Journal, Ian Ashdown, Vol 9, Num 8, August 1991,
- pp. 89-96.
-
- Printing PCX Files, C Gazette, Marv Luse, Vol 5, Num 2, Winter 1990-91,
- pp. 11-22.
-
- Reading GIF Files, Dr. Dobb's Journal, Wilson MacGyver Liaw, #227
- February 1995 (Vol 20, Issue 2), pp. 56-60.
-
- TIFF File Format, C Gazette, James Murray, Vol 5, Num 2, Winter 1990-91,
- pp. 27-42.
-
- Translating PCX Files, Dr. Dobb's Journal, K. Quirk, Vol 14, Num 8,
- August 1989, pp. 30-36, 105-108.
-
- Working with PCX files, Microcornucopia, Number 42, July-August 1988,
- p. 42.
-
- ------------------------------
-
- Subject: 5. U.S. Government and Military Standards Sources
-
- The following organizations provide U.S. Government and Military documents
- concerning graphics formats and standards:
-
- Department of Defense
- Joint Interoperability Engineering Organization
- Center for Standards
- 10701 Parkridge Boulevard
- Reston, VA 22091-4398 USA
-
- Standardization Documents Ordering Desk
- Building 4D
- 700 Robbins Avenue
- Philadelphia, PA 19111-5094 USA
-
- Naval Publications & Forms Center
- Code 3051
- 5801 Tabot Ave.
- Philadelphia, PA 19120 USA
-
- Defense Information Systems Agency
- Center for Standards
- Attn: TBCE, Rm 3304
- 10701 Parkridge Blvd
- Reston, VA 22091 USA
- Voice: 703.487.3536
- Email: edi@itsi.disa.mil
-
- Global Engineering Documents
- 2805 McGaw Avenue
- Irvine, CA 92714 USA
- Voice: 800.854.7179
- Voice: 714.261.1455
-
- ------------------------------
-
- Subject: 6. Other Standards Document Sources
-
- Many graphics file formats and graphical information transfer protocols are
- ANSI/ISO standards and may be obtained through the following offices:
-
- International Standards Organization (ISO)
- 1 rue de Varembe
- Case Postal 56
- CH-1211 Geneva 20 Switzerland
- Voice: +41 22 749 01 11
- Fax: +41 22 733 34 30
-
- American National Standards Institute (ANSI)
- Sales Department
- 1430 Broadway
- New York, NY 10018
- Voice: 212.642.4900
-
- Canadian Standards Association (CSA)
- Sales Group
- 178 Rexdale Blvd.
- Rexdale, Ontario, M9W 1R3
- Voice: 416.747.444
-
- ------------------------------
-
- Subject: V. Graphics Formats Misnomers, Misgivings, and Miscellany
-
- ------------------------------
-
- Subject: 0. Why aren't JPEG, MPEG, LZW, and CCITT Group 3 & 4 file formats?
-
- One of the most commonly confused concepts found in file formats is the
- difference between the file format and the method(s) of data encoding that
- has been used to reduce the size of the data the file contains. JPEG, MPEG,
- LZW, and CCITT are all algorithms, or algorithm toolkits, which encode a
- stream of data to a physically smaller size. None of these data compression
- methods define a specific format used to store data.
-
- Several formats have become popular based on their use of one or more of
- these methods of compression, such as GIF (LZW), JFIF (JPEG), and TIFF (CCITT
- Group 3 and Group 4). So if you ask for a "CCITT Group 3" image file you will
- most likely get a file containing only CCITT Group 3 data and not a TIFF file
- containing bitmapped data compressed using the CCITT Group 3 algorithm, which
- might have been what you were expecting.
-
- ------------------------------
-
- Subject: 1. Why aren't IGES, GKS, NAPLPS, and HPGL file formats either?
-
- IGES (Initial Graphics Exchange Specification), GKS (Graphics Kernel System),
- and NAPLPS (North American Presentation Layer Protocol Syntax) are not
- actually file formats. They are instead protocols which specify how graphical
- data should be transmitted over a communications link (such as a telephone
- line) to a remote device (such as a graphical workstation). HPGL
- (Hewlett-Packard Graphics Language) is a printer control language (PCL) used
- to transfer and manipulate data used by printers.
-
- In most cases, each of these protocols define a previously existing file
- format, such as CGM or JFIF, to be the actual format used to store the
- graphics data (HPGL uses a raw or compressed bitmap). Occasionally the
- transmitted data stream may be stored to a file for buffering or archival
- purposes. This file is then often identified as using the
- "{IGES,GKS,NAPLPS,HPGL} file format".
-
- Descriptions of each of these standards may be found in Part 3 (Where to Get
- File Format Specifications) of this FAQ.
-
- ------------------------------
-
- Subject: 2. Is it "Tag" or "Tagged" Image File Format?
-
- Revision 5.0 of TIFF specification specifically states the acronym "TIFF" is
- "Tag Image File Format". The majority of people, however, intuitively say
- "Tagged" rather than "Tag". Interestingly enough, the TIFF 6.0 specification
- does not spell out the acronym TIFF.
-
- ------------------------------
-
- Subject: 3. Whaddya mean there's no "Targa" file format?
-
- The popular "Targa" file format is really the "TGA format". "Targa" is the
- name of the Truevision graphics display adapter which first used the TGA
- format. Specifically, Revision 1.0 of TGA is designated the "Original TGA
- format" and Revision 2.0 is the "New TGA Format".
-
- ------------------------------
-
- Subject: 4. Choosy programmers choose "gif" or "jif"?
-
- The pronunciation of "GIF" is specified in the GIF specification to be "jif",
- as in "jiffy", rather then "gif", which most people seem to prefer. This does
- seem strange because the "G" is from the word "Graphics" and not "Jraphics".
-
- ------------------------------
-
- Subject: 5. Why are there so many ".PIC" and ".IMG" formats?
-
- Because people with very little imagination are allowed to choose file
- extensions for graphics files, that's why.
-
- But seriously, there does seem to be a proliferation of file formats with the
- file extension ".PIC" (for "picture") and ".IMG" (for "image"). Other popular
- extensions (in both upper and lower case) are ".RGB", ".RAW", ".ASC", and
- ".MAP".
-
- My advise to you is never assume the format of a data file based only on it's
- file extension. The name and the extension of any file are completely
- arbitrary and therefore could be anything. This is why the most graphics file
- conversion and display programs attempt to recognize graphics files based on
- their internal structure and not their file name or extension.
-
- ------------------------------
-
- Subject: 6. Is it now illegal to use CompuServe's GIF format?
-
- [ This section to be revised (I'm still trying to get the accurate poop) ]
-
- ------------------------------
-
- Subject: VII. Kudos and Assertions
-
- ------------------------------
-
- Subject: 0. Acknowledgments
-
- The following people have made this FAQ take just a little bit longer to read
- since the last time you looked at it (blame them and not me):
-
- John T. Grieggs <grieggs@netcom.com>
- Lee Kimmelman <lee.kimmelman@twwde.com>
- Tom Lane <tgl@netcom.com>
- Angus Montgomery <angus@cgl.citri.edu.au>
- Glen Ozymok <oz@ludwig.virtualprototypes.ca>
- Daniel Sears <sears@netcom.com>
- Bjoern Stabell <bjoerns@acm.org>
-
- ------------------------------
-
- Subject: 1. About The Author
-
- The author of this FAQ, James D. Murray, lives in the City of Orange, Orange
- County, California, USA. He is the co-author of the book Encyclopedia of
- Graphics File Formats published by O'Reilly and Associates, makes a passable
- living writing Microsoft Windows applications in C++, and may be reached as
- jdm@netcom.com, or via U.S. Snail at: P.O. Box 70, Orange, CA 92666-0070 USA.
-
- GCS d-- H++ s g- p? au+ a w+ v++ C+++(++++) US+++ p++>++++ L>++ 3 E--- N++ K-
- W---$ M-@ V-- po Y+ t++ 5-- j>x R+>-- G' tv-->! b+++ D++ B e- u* h- f r-->+++
- n++ y*(**)
-
- ------------------------------
-
- Subject: 2. Disclaimer
-
- While every effort has been taken to insure the accuracy of the information
- contained in this FAQ list compilation, the author and contributors assume no
- responsibility for errors or omissions, or for damages resulting from the use
- of the information contained herein.
-
- ------------------------------
-
- Subject: 3. Copyright Notice
-
- This FAQ is Copyright (C) 1994-95 by James D. Murray. All Rights Reserved.
- This work may be reproduced, in whole or in part, using any medium,
- including, but not limited to, electronic transmission, CD-ROM, or published
- in print, under the condition that this copyright notice remains intact.
-
-